home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1147 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.8 KB

  1. From: Stephen Usher <Stephen.Usher@earth.ox.ac.uk>
  2. Subject: Re: load average patches for MiNT 1.10 + patches
  3. Date: Sat, 5 Mar 1994 12:21:20 +0000 (GMT)
  4. In-Reply-To: <memo.597985@cix.compulink.co.uk> from "Darryl Piper" at Mar 4, 94 08:48:00 pm
  5. Mime-Version: 1.0
  6.  
  7.  
  8. >In-Reply-To: <2128.9403040748@elvis.earth.ox.ac.uk>
  9. >>> hmm.  i haven't tried but i would suggest just using the 200 Hz timer
  10. >>>counter (_hz_200) and doing calculations elsewhere...  because the 200 Hz
  11. >>>interrupt runs at level 6 and the longer you run at levels >= 5 (6) the
  12. >>>easier you lose characters on serial ports. (receiver overrun...)
  13. >>
  14. >>The calculations are only done once per second, so the impact on the system
  15. >>is minimal. The calculations themselves are merely a few adds, subtracts and
  16. >>divides, all integer arithmetic, so not particularly slow to do.
  17. >
  18. >I say use the VBL routine to check your timer, but check the 200 Hz
  19. >timer from in their. That way your one second timer will be accurate to
  20. >either 1/50, 1/60, 1/70 second. This will cut down on system overhead,
  21. >which is in my opion becoming too much for 8 MHz 68000s.
  22.  
  23. The overhead would not be significantly affected by moving the routine to
  24. the VBL, if anything it would be increased, see my original version of
  25. loadave for more details. Also, you are most likely to have clock drift due
  26. to the inaccuracy of the test's timing.
  27.  
  28. The bulk of the routine is only called once per second, every other 1/200th
  29. of a second a counter is merely decremented and tested, this is about 5
  30. instructions I believe, not much of an overhead at all.
  31.  
  32. The routine which is called once a second traverses the process table
  33. testing for processes on the run queue, adds them up, subtracts three values
  34. taken from three arrays after scaling them with a shift and a divide, places
  35. the total number of processes into three arrays, increments three pointers,
  36. scales the current load with a shift and three divides and adds the value
  37. the loadaverage values. Oh and it increments the uptime counter too.
  38.  
  39. Most of the time in this routine is taken traversing the process table, and
  40. this would happen once a second whatever way I implemented loadaverages.
  41.  
  42. >From experiments, the increase in overhead is so little that I couldn't
  43. measure the speed difference on my 520STM with 2.5MB RAM. (This is not my
  44. development system.. I use my TT and Sun 3/80 for that.)
  45.  
  46. >Bye now,
  47. >
  48. >  Darryl
  49. >
  50. >.----------------------------------------------------------------.
  51. >| email through the InterNet to :-   drpiper@cix.compulink.co.uk |
  52. >'----------------------------------------------------------------'
  53.  
  54. Steve
  55.  
  56. -- 
  57. ---------------------------------------------------------------------------
  58. Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
  59. E-Mail: steve@uk.ac.ox.earth (JANET) steve@earth.ox.ac.uk (Internet).
  60. Tel:- Oxford (0865) 282110 (UK) or +44 865 282110 (International).
  61.